Understanding When to Leverage RODCs
As you can see, branch
offices were faced with numerous challenges. Because of the many
features of RODCs, however, branch offices can now have domain
controllers on site without compromising security.
The main benefits of running RODC in branch offices are associated with the following:
Read-only Active Directory Domain Services
Reduced replication workload over the network
Credential caching
Administrator role separation
Read-Only DNS
Read-Only SYSVOL
These features of RODCs,
which are discussed in detail in the following sections, assist in
alleviating concerns and dilemmas for organizations.
Read-Only Active Directory Domain Services
Poor physical security is
typically the most common rationale for deploying an RODC at a branch
office. A read-only copy of the domain controller provides fast and
reliable authentication, while simultaneously protecting against data
loss in the event the server is compromised or stolen. Because no
changes can originate from an RODC, a malicious hacker or IT support
personnel with little knowledge of Active Directory administration
cannot make changes at the branch level. On a writable domain
controller, not only can changes be made, but these changes would
propagate to all other domain controllers, eventually damaging or
polluting the Active Directory domain and forest.
Reduced Replication Workload over the Network
As mentioned earlier, RODCs
do not participate in Active Directory replication in the same fashion
as writable domain controllers. Replication with RODC is one-way,
meaning all
changes from a writable domain controller are propagated to the RODC.
An RODC receives changes, but does not partake in or perform any
outbound replication to other domain controllers. This results in the
replication workload being minimized over the network because changes do
not have to be pulled from an RODC and because Active Directory
replication is unidirectional. Also reduced is the amount of time
required to monitor replication, which is another plus for having an
RODC.
Credential Caching
Credential caching with
an RODC provides numerous security enhancements for a domain controller
residing at a branch office. Take, for example, a new functionality in
RODCs that increases security in the event an RODC is stolen. When
replication transpires between a writable domain controller and an RODC,
only a user’s account information is replicated—not the user’s
password. Equally important, passwords are not stored on an RODC. In the
event the RODC is stolen, the only accounts that can be hacked and
compromised are the local administrator accounts and the RODC account,
which is specific to the RODC server. These accounts are not considered
to be highly privileged, nor do they have access authorization on the
forest and domain. On the other hand, traditional writable domain
controllers store both the user’s account information and password on a
domain controller, ultimately leaving users very vulnerable.
Because an RODC by default
does not store user accounts or passwords locally, branch office users
must authenticate against a writable domain controller in a hub site.
This is often not practical for branch office users, especially if the
WAN link between the sites is slow or unavailable. In this case, it is
possible to configure password replication caching for specific branch
office users on the branch office RODC. After the credentials are cached
on the RODC, the domain controller will service users the next time
they try to log on and every other time after that until the credentials
change. Typically, a branch office only has a few users, so only a
subset of an organization’s users’ accounts are cached on the RODC at
the branch office, limiting the exposure of credentials in the event of a
system breach.
To provide an additional
level of security and at the same time reduce the amount of information
exposed in the event an RODC is stolen, a domain administrator can use
tools within Active Directory Users and Computers to delete the RODC
from the Active Directory domain/forest and reset the passwords for user
accounts cached on the RODC.
Note
By default, security groups
with high privileges such as Domain Administrators and Enterprise
Administrators are configured to never allow their passwords to
replicate to RODCs.
Administrator Role Separation
Organizations are encouraged to
use RODCs when there is a need to satisfy unique administrative
requirements and to maintain administrator role separation and
isolation. The use of an RODC is especially encouraged if the domain
controller situated in a branch office hosts more than one server
function or server role, such as a print server, messaging server,
file server, and much more. The use of an RODC is also recommended when
there are other applications installed on the domain controller.
Traditionally, in this situation the administrator of these applications
has privileges not only to the applications, but also to the entire
Active Directory, which can pose a threat. With RODC, however, you can
delegate permissions to local administrators, granting them rights to a
particular server, roles, or LOB applications without ever granting them
access to Active Directory or domain resources beyond the scope of the
branch. As a result, the local administrator at the branch can perform
his or her administrator work activities effectively without
compromising the entire Active Directory environment.
Read-Only DNS
When using RODCs, it is
possible to add the DNS role/service to the RODC. After the DNS service
is added to an RODC, the RODC will replicate Active Directory–integrated
DNS information such as DNS-related AD partitions, including both the
ForestDNS and DomainDNS zones.
Running DNS on an RODC is
very similar to running DNS on a writable domain controller. Users can
query the local DNS server residing on the branch office RODC for A
records and other DNS-related items such as Internet requests. However,
unlike traditional writable domain controllers, DNS on RODC does not
support dynamic updates. The DNS zone information is entirely read-only.
If a client wants to update
their DNS A or PTR record in the local branch office, the RODC will send
a DNS replicate-single-object change request to a writable domain
controller running the traditional DNS service. The DNS change for the
client will occur on the writable DNS server and, eventually, the change
will be propagated back to the RODC via unidirectional Active Directory
replication.
Note
It is a best practice to
have clients in the branch office point to their local RODC DNS server
for DNS lookups. This can be achieved via an Active Directory group
policy or DNS lookup list based on DHCP.
Read-Only SYSVOL
In Windows Server 2008, it
was still possible for changes to be made to the sysvol folder of an
RODC. When changes were made to the contents of the sysvol folder, those
changes persisted until being overwritten by the next DFS Replication
cycle. In Windows Server 2008 R2, Microsoft made changes to the RODC
functionality such that the sysvol folder is now read-only on an RODC.
